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Abstract 

A C-program DIANA (Diagram ANAlyser) for the automatic Feynman diagram 

evaluation is presented. It consists of two parts: the analyzer of diagrams and the 

interpreter of a special text manipulating language. This language is used to create 

a source code for analytical or numerical evaluations and to keep the control of the 

process in general. 
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^ ■ 1 Introduction 

r- : 

Recent high precision experiments require, on the side of the theory, high-precision calcu- 
' lations resulting in the evaluation of higher loop diagrams in the Standard Model (SM). 

For specific processes thousands of multiloop Feynman diagrams do contribute, and it 
■ turns out to be impossible to perform these calculations by hand. This makes the request 
^3" ! for automation a high-priority task. 

Several different packages have been developed with different areas of applicability 
(see a good review 0). For example, FEYNARTS / FEYNCALC § are MATHEMA- 
TICA packages convenient for various aspects of the calculation of radiative corrections 
in the SM. There are several FORM packages for evaluating multiloop diagrams, like 
Ph! MINCER |J, and a package Q for the calculation of 3doop bubble integrals with one 
non-zero mass. Other packages for automation are GRACE || and COMPHEP || , which 
partially perform full calculations, from the process definition to the cross-section values. 

A somewhat different approach is pursued by XLOOPS 0. A graphical user inter- 
face makes XLOOPS an 'easy-to-handle' program package, but is mainly aimed to the 
evaluation of single diagrams. To deal with thousands of diagrams, it is necessary to use 
special techniques like databases and special controlling programs. In M for evaluating 
more than 11000 diagrams the special databasedike program MINOS was developed. It 
calls the relevant FORM programs, waits until they finished, picks up their results and 
repeats the process without any human interference. 

The package GEFICOM || , developed for computation of higher order processes in- 
volving a large number of diagrams, is based on cooperative usage of several software 
tools such as Mathematica, FORM, Fortran, etc. 

It seems impossible to develop an universal package, which will be efficient for all 
tasks. It appears absolutely necessary that various groups produce their own solutions 
of handling the problem of automation: various ways will be of different efficiency, have 
different domains of applicability, and last but not least, should eventually allow for 
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completely independent checks of the final results. This point of view motivated us to 
seek our own way of automatic evaluation of Feynman diagrams. 

Our first step was dedicated to the automation of the muons two-loop anomalous mag- 
netic moment (AMM) ^(g — 2) (j . For this purpose the package TLAMM was developed 
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||10|| . The algorithm is implemented as a FORM-based program package. For generating 
and automatically evaluating any number of two-loop self-energy diagrams, a special di- 
program has been written. This program creates the initial FORM-expression for every 
diagram generated by QGRAF []TTJ , executes the corresponding subroutines and sums up 
the various contributions. In the SM 1832 two-loop diagrams contribute in this case. The 
calculation of the bare diagrams is finished. 

Our aim is to create some universal software tool for piloting the process of generating 
the source code in multi-loop order for analytical or numerical evaluations and to keep 
the control of the process in general. Based on this instrument, we can attempt to build 
a complete package performing the computation of any given process in the framework of 
any concrete model. 



2 Brief description 

For the project called DIANA (Diagram ANAlyser) for the evaluation of Feynman dia- 
grams we have elaborated a special text manipulating language (TM). The TM language 
is a very simple TeX-like language for creating source code and organizing the interactive 
dialog. 

The program reads QGRAF output. For each diagram it performs the TM-program, 
producing input for further evaluation of the diagram. Thus the program: 
Reads QGRAF output and for each diagram it: 

1. Determines the topology, looking for it in the table of all known topologies and 
distributes momenta. If we do not yet know all needed topologies, we may use the 
program to determine missing topologies that occur in the process. 

2. Creates an internal representation of the diagram in terms of vertices and propaga- 
tors. 

3. Executes the TM-program to insert explicit expressions for the vertices, propagators 
etc. The TM-program produces input text for FORM ( or some other language), 
and executes the latter (optionally). 

Using the TM language, advanced users can develop further extensions, e. g. including 
FORTRAN, to create a postscript file for the picture of the current diagram, etc. 

The program operates as follows: first of all, it reads its configuration file, which may 
be produced manually or by DIANA as well. This file contains: 

1. The information about various settings (file names, numbers of external particles, 
definition of key words, etc.) 

2. Momenta distribution for each topology. 
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Figure 1: Typical flowchart of Feynman diagram evaluations by DIANA. 

3. Description of the model (i. e., all particles, propagators and vertices). 

4. TM-program. 

The TM-program is part of the configuration file. It starts with the directive 
\begin translate 

Then the program starts to read QGRAF output. For each diagram it determines 
the topology, assigns indices and creates the textual representation of the diagram corre- 
sponding to the Feynman integrand. All defined data (masses of particles, momenta on 
each lines, etc.) are stored in internal tables, and may be called by TM-program opera- 
tors. At this point DIANA performs the TM-program. After that it starts to work with 
the next diagram. 

When all diagrams are processed, the program may perform the TM-program a last 
time (optionally). This may be used to do some final operations like summing up the 
results. 
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Use of the TM language makes DIANA very flexible. It is easy to work out various 
algorithms of diagram evaluation by specifying settings in the configuration file or even 
by a TM program. 

The typical flowchart may look like in Fig. [T]. 

There is a possibility to use DIANA to perform the TM-program only, without reading 
QGRAF output. If one specifies in the configuration file 

only interpret 

then DIANA will not try to read QGRAF output, but immediately enters the TM - 
program. 

DIANA contains a powerful preprocessor. The user can create macros to hide com- 
plicated constructions. Similar as LaTeX provides the possibility for non-specialists to 
typeset high-quality texts using the TeX language, these macros permit DIANA to work 
at very high level. The user can specify the model and the process, and DIANA will 
generate all necessary files. 

3 Topologies and momenta 




Figure 2: Topology (-2,2)(-l,l)(5,l)(l,3)(3,4)(4,2)(2,5)(5,6)(3,6)(4,6). 

Topologies are represented in terms of ordered pairs of numbers like (fromvertex, 
tovertex) (see Fig. 0). All external legs have negative numbers. These are supposed to 
begin with -1. First one attaches all the numbers for the ingoing particles, and then for 
the outgoing ones. External legs must be connected with vertices of smallest possible 
identifying number. The number of an internal line corresponds to its position in the 
chain of pairs and the direction from the first to the second number in the pair: 

direction: 5 -> 1 1^3 3^4 4^2 2^5 5^6 3^6 4-^6 
(-2,2)(-l,l) (5,1) (1,3) (3,4) (4,2) (2,5) (5,6) (3,6) (4,6) 
number: 12345678 

Knowing thus the topology we can assign momenta. Their distribution according to Fig. 
0, e. g., is added like 

topology A = (-2, 2) (-1,1) (5,1) (1,3) (3,4) (4, 2) (2, 5) (5,6) (3, 6) (4, 6): 
pl,p2,p3,p4,p5,p6,p7,p8; 
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This fixes directions and values of all momenta on internal lines. External lines must be 
known from the process definition. By convention the external lines must start with the 
highest negative number. 

Ali topologies have to be described in the configuration file. DIANA stores topologies 
in an internal table in some Standard form. After reading a new diagram DIANA defines 
its topology, reduces the topology to the Standard form and searches for the topology in 
the table. If DIANA fails to find the topology, it will not produce the Feynman integrand 
for the diagram. 

4 TM language 

Similar to the TeX language, all lines without special escape - characters ("\") are simply 
typed to the output file. So, to type "Hello, world!" in the file "hello" we may write down 
the following program: 

\program 
\setout (hello) 
Hello, world! 

The asterisk in the beginning of line is a comment: 
* This is the comment! 

Each word, the first character of which is the escape character, will be considered as 
a command. This feature makes this language very easy-to-use. In appendix A there is 
an example of a simple TM-program and the result of its performance. 

DIANA's preprocessor is run on the TM program before actual compilation. It permits 
the user to do textual substitutions (with parameters), to perform conditional compilation, 
etc. For example, the following preprocessor directive 

\DEF(macroname) 
\ENDDEF 

sets the macro definition. After this directive you can just write 
\macroname () 

to invoke the macro. You can use macros with arguments: 
\macroname (a, b , c) 

In the macro body the arguments are available by the directive \#(n), where "n" is the 
position of the argument. The argument "0" is the macro name, all extra arguments are empty 
strings. 

Example: 
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only interpret 
\begin translate 

\DEF(EXAMPLE) 0=\#(0) , 1=\#(1) , 2=\# (2) , 3=\# (3) \ENDDEF 

\program 

\of f blanklines 

\setout () 

\EXAMPLE(a,b) 

\end translate 

The result is: 

0=EXAMPLE , l=a , 2=b , 3= 

Using macros we are able to create a high level macrolanguage similar to LaTeX, 
which is the set of macrodefinitions under TeX. The basic idea is again similar to LaTeX, 
namely the use of styles. Instead of complicated TM programming one can use proper 
styles. The style file containing all macrodefinitions is just included in the beginning of 
the TM program. We have several such styles oriented to the use of FORM. 

5 Generating configuration files 

The style "create. tml" has the purpose to create the TM program. The user has to prepare 
a file "process.cnf", which contains the model and process specifications. Reading this 
file, DIANA will generate all necessary other files. A typical example of such a file is the 
following. 

SET _processname = "zbb" 

SET _qgrafname = "qgraf" 

SET _syspath = "/home/U. Ser/diana/tml/" 

system path = "/home/U. Ser/diana/tml/" 

only interpret 

\openlanguage (create . tml) 
\Begin (program) 

\Begin (model, gwsmassless .model) 
\End (model) 

\Begin (process) 
ingoing Z(mu;pl) ; 
outgoing b(;kl) ,B(;k2) ; 
loops = 2; 
\End(process) 

\Begin(qgraf options) 
options=onepi ,nosnail ; 
\End ( qgr af opt i ons ) 
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\Begin ( tmlprogram , f orm . prg) 
\End (tmlprogram) 

\indices (mu , mul , mu2 , mu3 , mu4 , mu5 , mu6 , mu7 , 

mu8 ,mu9 ,mulO ,mull ,mul2 ,mul3,mul4,mul5 ,mul6 ,mul7 ,mul8,mul9 ,mu20 ,mu21 ,mu22 ,mu23) 
\vectors (pl , p2 , p3 , p4 , p5 , p6 , p , q , ql , q2 , kl , k2) 

\End (program) 

This file contains all necessary information to create files for DIANA to proceed the 
process Z — > bb in the framework of the SM. In the following we explain details of the 
above file. 

Directives of the type SET var = "val" are used to set predefined preprocessor vari- 
ables. Thus, the directive 

SET _processname = "zbb" 

just defines the name of the process. It will be used as filename extension for all created 
files. 

SET _qgrafname = "qgraf" 

defines the command to invoke QGRAF. The directives 

SET _syspath = "/home/U. Ser/diana/tml/" 
system path = " /home/U. Ser/diana/tml/" 

are used to define the path to files containing TM macros and subroutines. The value of 
the preprocessor variable _syspath will be used by DIANA to define the line 

system path = "/home/U. Ser/diana/tml/" 

in the created file "settings.zbb" . In principle in "process.cnf" and "settings.zbb" these 
two paths may be different. 

The directive 
only interpret 

tells DIANA not to read QGRAF output but just to perform the TM program. 

The directive: 

\openlanguage (create . tml) 

is equivalent to the two directives 

\begin translate 
\include (create .tml) 
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The first one starts the TM language and the file create .tml contains all macro definitions 
and subroutines. In particular, it contains the definition of the macros \Begin() and 
\End ( ) . These macros form an environment depending on the first argument of the macro 
\Begin(). 

The Body of the TM program is supposed to be placed between 
\Begin (program) 

\End (program) 

Text after \End (program) will be ignored. 

The environment 

\Begin (model, gwsmassless .model) 
\End (model) 

defines the model description. Instead of explicit definition, in this example the file 
"gwsmassless. model" is used. This is a file containing a simplified version of the SM. It 
should be placed in the directory /home/U.Ser/diana/tml/ in order that DIANA can find 
it in "process.cnf" . 

The process definition is clear from 

\Begin(process) 
ingoing Z(mu;pl) ; 
outgoing b(;kl) ,B(;k2) ; 
loops = 2; 
\End(process) 



The following environment defines the options passed to QGRAF |l I 



\Begin(qgraf options) 
options=onepi ,nosnail ; 
\End ( qgr af opt i ons ) 

The TM program for evaluating Feynman diagrams must be placed in the environment 

\Begin (tmlprogram) 
\End(tmlprogram) 

Instead one may specify the file containing the TM program as second argument: 
\Begin (tmlprogram , f orm . prg) 

Here "form. prg" is the name of the file containing the Standard TM program for evaluation 
of Feynman diagrams by means of FORM. 

The macros \indices() and \vectors() specify used indices and vectors. 
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6 The structure of the generated files 



Suppose the executable files "diana" and "qgraf" are available from the system path and 
the files "create.tml" , "gwsmassless. model", "form.prg" and "process.cnf" are situated in 
the directory "/home/U.Ser/diana/tml/" or in the current directory. 
The user starts DIANA by means of the command 

diana -c process.cnf 

DIANA then generates several temporary files, invokes QGRAF, defines all topologies 
of the process and distributes momenta as follows: the first line in each topology will 
carry momentum pl, the second p2, etc. Three new files appear in the current direc- 
tory: "config.zbb", "qlist.zbb" and "settings.zbb" . The file "config.zbb" contains the 
TM program for the evaluation of the Feynman diagrams of the specific process under 
consideration. "settings.zbb" contains various optional settings, topologies and momenta 
description, the model and the process definition. It can be edited e. g. for the purpose of 
introducing proper integration momenta for the various topologies by replacing the pi's. 
The file "qlist.zbb" is the QGRAF output file. To start the calculation of the Feynman 
diagrams the user finally enters the command 

diana -c config.zbb 

For the above example Z — > bb the topologies in the file "settings.zbb" are: 

topology topl_= 

(-3,3) (-2, 2) (-1,1) (1,2) (1,3) (1,4) (2, 4) (3, 4) : 
pl,p2,p3,p4,p5; 
topology top2_= 

(-3, 3) (-2, 2) (-1,1) (1,3) (1,4) (1,4) (2, 3) (2, 4) : 
pl,p2,p3,p4,p5; 
topology top3_= 

(-3, 3) (-2, 2) (-1,1) (1,2) (1,4) (1,4) (2, 3) (3, 4) : 
pl,p2,p3,p4,p5; 
topology top4_= 

(-3,3) (-2,2) (-1,1) (1,4) (1,4) (2,3) (2,4) (3,4) : 
pl,p2,p3,p4,p5; 
topology top5_= 

(-3, 3) (-2, 2) (-1,1) (1,4) (1,5) (2, 4) (2, 5) (3, 4) (3, 5): 
pl,p2,p3,p4,p5,p6; 
topology top6_= 

(-3, 3) (-2, 2) (-1,1) (1,2) (1,4) (2, 5) (3, 4) (3, 5) (4, 5): 
pl,p2,p3,p4,p5,p6; 
topology top7_= 

(-3, 3) (-2, 2) (-1,1) (1,3) (1,4) (2, 4) (2, 5) (3, 5) (4, 5): 
pl,p2,p3,p4,p5,p6; 
topology top8_= 

(-3, 3) (-2, 2) (-1,1) (1,4) (1,5) (2, 3) (2, 4) (3, 5) (4, 5): 
pl,p2,p3,p4,p5,p6; 
topology top9_= 

(-3, 3) (-2, 2) (-1,1) (1,2) (1,3) (2, 4) (3, 5) (4, 5) (4, 5): 
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pl ) p2,p3,p4,p5,p6; 
topology toplO_= 

(-3, 3) (-2, 2) (-1,1) (1,2) (1,4) (2, 3) (3, 5) (4, 5) (4, 5): 
pl,p2,p3,p4,p5,p6; 
topology topll_= 

(-3, 3) (-2, 2) (-1,1) (1,3) (1,4) (2, 3) (2, 5) (4, 5) (4, 5): 
pl,p2,p3,p4,p5,p6; 

The user must edit this file to set the desired integration momenta and the internal 
numeration of lines according to the rules described in Sect. |[ In the near future the 
pictorial representation of the topologies will be implemented. 

As next we give a detailed description of the file "config.zbb" . It contains the directive 
to include the file "settings.zbb" , several settings for various options and a skeleton of the 
FORM program in terms of the TM language. The following is a listing of the file. The 
whole TM-program is divided into different "sections". Each section will be performed 
only under proper conditions. 

* This file is automatically generated by DIANA for the process zbb. 
\include (settings .zbb) 

*Remove the following to avoid the generation of the protocol file: 
log file = log. zbb 

* Remove the following line to avoid debug information: 
debug on 

extra call 

\openlanguage(specmode . tml) 
\Begin(program,routines .rtn) 

\section(regular) 

\Begin(initialization) 

\export (callf orm, \ask(\ (Call f orm? (Y/N) ) ) ) 
\End(initialization) 

\Begin(output , \askf ilenameO ) 
**** d\counter() 

**** (diagram \currentdiagramnumber () ) 
\blankline() 

* Set here your defines! 

\Begin(f oreach, i , 1 , \numberof internallinesO ) 

#define mm\i() "\mass (\i () ) " 

\blankline () 
\End (f oreach) 

#define LINE "\numberof internallines () " 
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#define FERMIDNLINE "\maxf count () " 

#define T0P0L0GY "\topologyid() " 

\blankline() 

functions \functions () ; 

commuting \commuting() ; 

1 Rq =\integrand() ; 

\blankline() 

* Here should be your FORM program! 
drop Rq; 

g dia\counter ()=Rq; 
. store 

save dia\counter () . sto ; 
. end 
\End(output) 

\Begin(special , "\import (callf orm) "eq"Y") 

\execute(\(f orm -1 ) ! . !) 
\End(special) 

\sect ion (epilog) 

\Begin(output) 

#do j = l,\counter() 
load dia' j ' . sto ; 
. store 
#enddo 
g Rq = 

#do j = l,\counter() 

+ dia' j ' 
#enddo 
> 

. sort 
print ; 
. end 
\End(output) 

\Begin(special , "\import (callf orm) "eq"Y") 

\execute (\ (f orm -1 )!.!) 
\End(special) 

\End (program) 

The setting log file = log.zbb induces the creation of the protocol file "log.zbb". 

If the user sets debug on, DIANA will produce a detailed record of the translation process. 
Some information necessary for possible run-time diagnostics will be stored as well. 

The setting extra call forces DIANA to perform the TM-program once again after all 
diagrams are processed. In this case only the section epilog will be called (see below). 
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In the next command the TM-program uses the macro - style "specmode.tml": 
\openlanguage (specmode . tml) 

This style defines the "sections" mechanism: a TM-program may consist of several "sec- 
tions" , each of them being performed only under certain conditions. So the generic struc- 
ture of the TM-program looks like follows: 

\Begin (program) 
\section(sectionname) 
(content . . . ) 

\End (program) 

The main section is \section(regular) . It is performed to create FORM input for each 
diagram. 

The section 

\sect ion (epilog) 

will be performed during "extra call" after all diagrams have been processed. In the above 
example this section is used to sum up the final results. 
The whole TM-program is put into the environment 

\Begin(program,routines .rtn) 
\End (program) 

It contains the argument "routines.rtn". This is the name of a file containing various 
TM-functions and macros, which are loaded in this manner, e. g. 

\functions() - outputs a comma - separated list of all non-commuting functions occuring 
in the current diagram and 

\commuting() - outputs the list of all commuting functions. 

In our example the global variable "callform" is defined by means of the function 
\ask(). This function outputs the argument to the screen waits for the user to reply "y" 
or "n" and returns "Y" or "N" , respectively, i. e. "callform" then takes the value "Y" or 
"N" . This action is placed in the environment 

\Begin(initialization) 
\End(initialization) 

and thus is performed only once. 

The section "regular" contains the skeleton of the FORM program. Output, i. e. the 
FORM input, inside the environment 

\Begin (output , f ilename) 
\End (output) 
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is directed into the file "filename" . In the above example, instead of an explicit file name, 
we use the macro \askf ilenameO defined in the style file specmode.tml. This macro 
asks the filename from the user. For each diagram a filename of the type"d.f rm" will be 
expanded to "d#.frm", where # is the number of the current diagram. Thus, for diagram 
number 15 the file "dl5.frm" will be created. Note that this expansion is performed by the 
environment and not by the macro \askf ilenameO . 

The macro \askf ilenameO asks the file name only once in the case when the file name 
is not defined yet. It is impossible to change the file name once entered. 

The macro \counterO counts the processed diagrams. It can differ from the diagram 
number (produced by QGRAF for the set of all diagrams) returned by the operator 
\currentdiagramnumber ( ) . 

The operator \blankline O returns a blank line. It must be used to obtain a blank 
line in the produced output because all blank lines in the TM-program are suppressed by 
default. 

There is the environment for each providing a "cycle with parameter". The content 
of the environment 

\Begin(f oreach, i , 1 , 10) 
\End(f oreach) 

will be repeated 10 times. Each time the macro \i() expands to the digit counter, i. e 
1,2,...10. 

The built-in operator \numberof internallines()returns for each diagram the number 
of internal lines; the built-in operator \maxf count () returns the number of connected 
fermion lines in the current diagram. 

The macro \integrandO is expanded in a sequence of TM-operators providing the 
Feynman integrand for the current diagram. 

There is the environment special. It has the form 

\Begin(special , <condition>) 
\End(special) 

The content of this environment will be performed only if <condition> evaluates to 
True. 

In the folowing example this environment is used to call FORM: 

\Begin(special , "\rmport (callf orm) "eq"Y" ) 

\execute(\(f orm -1 ) ! . !) 
\End(special) 

The macro \execute() expands the symbols ! . ! to the full file name (e. g., dl5.frm). The 
expression ! . is expanded to the file name without extension, and . ! is expanded to the 
extension. The macro \execute() calls the built-in TM-operator \system() to execute 
FORM. Thus, for the diagram number 15, e. g., the following command will be fulfilled: 

form -1 dl5.frm 

Here we assume that the user has entered the filename "d.frm". 

The section "epilog" uses the environment "output" without a second argument. The 
second argument is unnecessary because the file name is already defined. 

In the "extracall" the environment "output" uses the filename exactly the user has specified 
it, answering the question from the macro \askf ilenameO , i. e. "d.frm" in this case. 



13 



7 Generating the FORM input and executing FORM 



DIANA has many command line options. In particular, the user can specify the numbers of the 
diagrams to be evaluated. The command 

diana -c config.zbb -b 451 -e 453 

tells DIANA to process diagrams number 451, 452 and 453. After executing this command 
four new files appear in the current directory. If the user has entered the file name "d.frm" 
these files are: "d451.frm", "d452.frm", "d453.frm" and "d.frm". The content of the file 
"d.frm" looks like follows: 

#do j = 1,3 

load dia' j ' . sto ; 

. store 
#enddo 
g Rq = 
#do j = 1,3 
+ dia' j ' 
#enddo 
> 

. sort 
print ; 
. end 

It can be used by FORM to sum up the calculated diagrams. 
The file "d452.frm" looks like follows: 

**** d2 

**** (diagram 452) 

* Set here your defines! 
#define mml "mmt" 

#define mm2 "mmt" 

#define mm3 "0" 

#define mm4 "0" 

#define mm5 "0" 

#define mm6 "mmt" 

#define LINE "6" 
#define FERMIONLINE "2" 
#define T0P0L0GY "top8_" 



functions F,FF; 
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commuting VV; 
1 Rq = 

(-l)*F(2,l,mul,l,0,l)*(-i_)*em*Qd*FF(3,l,-p3,0)*i_* 

F(3, l,mu3, 1,0, l)*(-i_)*em*Qd*F(l,2,mu,GVu,-GAu, l)*(+i_)*em/2/s/c* 

FF(l,2,-pl,mt)*i_*F(4,2,mu2, 1,0, l)*(-i_)*em*Qu*FF(6,2,-p6,mt)*i_* 

F(5,2,mu4, 1,0, l)*(-i_)*em*Qu*FF(2,2,+p2,mt)*i_* 

VV (4 ,mul ,mu2 , +p4 , 0) *i_*VV (5 ,mu3 ,mu4 , +p5 , 0) *i_ ; 

* Here should be your FORM program! 
. end 

From the beginning of this file we can see that the macro \counter() produces 
the order number of the processed diagram, i. e. 2, while the built-in TM operator 
\currentdiagramnumber() produces the number of the current diagram according to the 
QGRAF file "qlist.zbb" i.e. 452 

*--#[ d452: 
* 

-1 

*vx(B(-2),b(l),A(2)) 
*vx(B(l),b(-4),A(3)) 
*vx(T(5),t(4),Z(-l)) 
*vx(T(4),t(6),A(2)) 
*vx(T(6),t(5),A(3)) 

* 

*--#] d452: 



Figure 3: To the left there is the QGRAF output for the diagram "number 452". t and 
T stand for t and anit-t quarks, b and B stand for b and anit-b quarks, A is the photon, 
Z is the Z boson. External legs are numerated by negative numbers and vx stands for 
the vertex. The corresponding graph is shown on the right. The lines are numbered 
corresponding to QGRAF output. The numbers in brackets correspond to the numbering 
defined by "topology 8" in the file "settings.zbb" . Bold italic digits numerate vertices 
according to the topology 8. 

In Fig. |H the QGRAF output for the diagram number 452 is shown together with 
the corresponding graph. We can see that in this case there are two fermion lines, one 
corresponding to the external b — b, while the second appears as closed fermion loop, the 
t quark triangle. That is why the #define "FERMIONLINE" is equal to "2". 

In order to understand the Feynman integrand structure in the above example we 
consider the simplified SM in use, i.e. the "gwsmassless. model" . In our example is 
contained in the file "settings.zbb" . The following notation is used: 
em - electromagnetic coupling (em > 0); 
s - sin(9 w ); 
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c - cos(9w)', 

mt, mW, mZ, mH - masses; 

mmt, mmW, mmZ, mmH - masses squared; 

Qe, Qu, Qd - electric charges in units of the proton charge, i. e. -1, 1/3, -2/3; 
GAe , GAnu , GAu , GAd - axial couplings; 
GVe , GVnu , GVu , GVd - vector couplings; 

We have two (c)functions for propagators: FF and VV. 
Vector propagator: 
VV( 

1 . number of line 

2. index of the first particle 

3. index of the second particle 

4. type (0 - photon, 1 - Z, 2 - W, 3-gluon) 

) 

Fermion propagator: 

FF( 

1. number of line 

2. fermion line number 

3. mass 

) 

For vertices we have one commuting function V and one function F. 

• The first argument always is the number of the vertex. 

• The last argument shows the type of the vertex: - scalar, 1 - vector, 2 - tensor, 
3 - VW, 4 - VVVV 

• The function F carries as second argument the fermion line number. 
For example, the fermion-vector-fermion vertex is: 

F( 

1. number of line 

2. fermion line number 

3. index 

4. GV (vector coupling) 

5. GA (axial coupling) 

6. 1 (the type of vertex 

) 

Note that the "gwsmassless. model" assumes a zero b quark mass (see #def ine mm3 "0"). 
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8 Conclusion 



Higher order loop calculations and/or multileg ones in one-loop order in the SM of elec- 
troweak interactions require the calculation of many complicated Feynman diagrams, 
which is due to the large particle spectrum of the model. The number of diagrams can 
exeed many thousands. Therefore the evaluation of such large number of diagrams needs 
to be automated in almost all respects. First of all an automation of the diagram gen- 
eration is needed. Since FORM, in our opinion, is the most suitable language for such 
kind of calculations, we found it of urgent need to write a program for this purpose which 
directly produces "FORM input", i. e. produces an algebraic representation of Feynman 
diagrams in terms of their momentum representation, written in FORM format. This is 
what the presented program DIANA is able to do at present and we believe it will have 
wide applications. For an application of DIANA for the process Z —>■ bb see ( ||1 2|| ) . 

In further steps techniques of handling the numerators and evaluation of scalar Feyn- 
man diagrams must be included. These methods partially exist already (ITO, |T3|). 
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Appendix A. Example of a simple TM-program 



In this appendix we consider a "pure" TM-program without macrocoding. This should 
help to understand some basis of the TM language. 

Let us suppose that we use FORM as formulae manipulating language. 

The user types his FORM program and has the possibility to insert in the same line 
TM-operators as well. For example, the typical part of a TM program looks like follows: 

\program 

\setout (d\currentdiagramnumber () . f rm) 

#define dia "\currentdiagramnumber () " 

#define TYPE "\typeO" 

#define COLOR "\colorO" 

#define LINES "\numberof internallines () " 

\masses () 

#include def.h 

1 R=\integrand() ; 

#call f eynmanrulesO 

#call projectionO 

#call reducing-C'TYPE'} 

#call table-C'TYPE'} 
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#call colorfactor{'COLOR'} 
. sort 

g dia'dia' = R; 
drop R; 
. store 

save dia' dia' . sto ; 
. end 

\setout (null) 

\system(\(f orm -1 )d\currentdiagramnumber () .frm) 

Some of the TM - commands are just TM-operators while some are functions (return- 
ing a value) written in the TM-language itself. 

Only one type of data exists in the TM language. This is a string. Ali operators and 
functions return only one text string. They may have one or more arguments, or may 
have no argument at all. Arguments are separated by commas. Number of arguments 
is fixed for each operator or function. The default value returned by any function is an 
empty string. 

The following operators are built-in TM operators: 
\numberof internallines () - returns the number of internal lines. 
\currentdiagramnumber() - returns the order number of current diagram. 
\setout(f ilename) - redirects output to the file "filename". There is the special file 
"null"; output redirected to this file never appears. If an empty string is used as argu- 
ment of this operator, the output will appear at the terminal. The above operator always 
returns an empty string. 

\system(cmd) - calls the operating system to perform the command "cmd". It returns 
some integer number for the system status of this command. 

An argument of any operator may contains an arbitrary number of other operators. 
All spaces in the operator arguments are suppressed. 

There is the special "quotating operator" without name, it just returns its argument 
without any change: \(any text) returns the string "any text". In the above example it 
is used in the argument of the operator \system() to keep spaces. 

The functions 

\masses(), \type(), \color() , \integrand() 

are TM-language functions. Their code should be placed somewhere before the main 
program (the latter starts with the operator \program). As an example we present the 
function "masses": 

\function masses ; \-\let (i , 0) 
\+\do 

#define m\inc(i,l) "\mass (\get (i) ) " 

\while "\numcmp(\get (i) ,\immberof internallines () ) " eq "<" loop 
\end 

This function just outputs a string like 
#define ml "mmH" 
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for each internal line. The built-in operator \mass(l) returns the mass of the particle at 
line 1. 

Some string may be stored in a variable. The operator \let (var , val) creates (or resets) 
variable var and gives it the value val. The operator \get(var) returns val: 

\program 

\let (who , world) 

\setout () 

Hello, \get(who)! 

Note, the operator \let(var, val) returns val, not an empty string! 

There are several built-in operators for manipulating integer numbers. In the above example 
of the function \masses() the operator \inc (i , 1 ) increments value of i by 1 and returns the 
new value. The operator \numcmp(a,b) returns "<", ">" or "=", depending on the numerical 
values of a and b. 

Variables defined by the operator \let() are local w. r. t. TM-functions. The user can 
define global variables by means the operator \export(var,val). Global variables exist 
during processing all diagrams. They can be obtained by the operator \import (val) . 

Unlike built-in operators, the user - defined functions can produce some output to the current 
output file. The function \masses(), e. g., returns an empty string, but it produces several 
lines placing them into the output file. That is why we use derictives \- and \+: the former 
just suppresses any output while the latter again permits output. 

Functions can return arbitrary strings by means of the operator \return(text) . 

There are several kinds of "controlling constructions" . They are used to change the stream 
of the control. These are the well - known "if", "do", etc. In the function \masses() you can 
see how the post-condition cycle is used. 

This TM-program will generate the FORM input for each diagram. For example, the 
corresponding part of the FORM program generated for diagram number 15 will be placed 
into the file "dl5.frm" and looks like follows: 

#define dia "15" 
#define TYPE "4" 
#define COLOR "3" 
#define LINES "4" 
#define ml "mmH" 
#define m2 "mmW" 
#define m3 "mmW" 
#define m4 "mmH" 
#include def.h 
1 R= 

l*V(l,mul ) mu ) 2)*(-i_)*em"2/2/s*V(2,0)*(-i_)*l/4*em~2/s"2*mmH/mmW* 
V(3,mu2,+q4-(+q3) , 1) * (-i_) *em/2/s*SS (1 , 0) *i_*VV(2 ,mul ,mu2 , +q2 , 2) *i_* 
SS(3,2)*i_*SS(4,0)*i_; 

#call f eynmanrules{} 

#call projectionO 

#call reducing{'TYPE'} 

#call table{'TYPE'} 

#call colorfactor{' COLOR'} 

. sort 
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drop R; 

g dia'dia' = R; 
. store 

save dia' dia' . sto ; 
. end 

Then this program will be performed by FORM by means of the operator 
\system(\ (f orm -1 )d\currentdiagramnumber() .f rm) 
In this case the operator performs the command 
f orm -1 dl5.frm 
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